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Description 

This invention relates to the field of data processing and, more particularly, to improvements in device driver sys- 
tems whereby a substantial portion (herein called "core") of a device driver system has a generic operating system 
5 interface allowing such core to be used with different operating systems without having to make any substantial changes 
to the core. 

By way of background, device drivers are programs or routines which control or manage the flow of data to and 
from I/O devices. The drivers form part of and interact with other portions of an operating system. An operating system 
normally includes a basic set of device drivers for I/O devices, such as a keyboard, fixed and floppy disks, display, and 

10 printer, commonly used in a personal computer. When an I/O device is added to a data processing system, and such 
device is not operable under an existing driver, a new driver must be added to the system in order to use the device. 
Such new driver is customarily supplied by the maker of the I/O device and is installed in the system in accordance 
with procedures established by the operating system. In personal computers operating with IBM DOS or OS/2 operating 
systems, such drivers are installed, when the computers are started or rebooted, using commands or instructions in a 

15 CONFIG.SYS file. 

Typically, device drivers are created for use with a particular operating system. A. M. Mizell, "Understanding device 
drivers in Operating System/2", IBM Systems Journal, Vol. 27, No. 2, 1988, pp. 170-184, describes the relationships 
of device drivers to the IBM OS/2 operating system. Such operating system provides multitasking operations in which 
different programs are able to concurrently use a single device, and one or more programs uses different devices at 

20 the same time. Quite obviously, the device drivers and device management routines are quite complex, and they have 
usually been operating system dependent. A device driver written for one operating system cannot be used with another 
operating system without extensive modifications. 

High performance models of the IBM PS/2 personal computers include a bus designed in accordance with Micro 
Channel architecture. (IBM, OS/2, PS/2 and Micro Channel are trademarks of International Business Machines cor- 

25 poration). Such bus is referred to hereinafter as an "MC bus" and provides the means by which additional \ZO devices 
and subsystems can be connected to the personal computers. A SCSI (Small Computer System Interface) bus is a 
bus designed in accordance with SCSI architecture, and provides a standardized design for the attachment thereto of 
I/O devices known as SCSI devices, that is, devices specifically designed for attachment to a SCSI bus. SCSI archi- 
tecture defines a SCSI command set for accessing SCSI devices. A SCSI adapter and a SCSI ABIOS (advanced basic 

30 input/output operating system) are commercially available and allow SCSI devices to be connected to PS/2 computers 
through an MC bus. A device driver system for such SCSI devices is disclosed in US patent 5 307 491 for SCSI DEVICE 
DRIVERS FOR MULTITASKING OPERATING SYSTEM, by D T Feriozi Jr et al, and assigned to the assignee of the 
invention claimed herein. In the system disclosed in such application, the SCSI device drivers were created specifically 
for use with OS/2 operating system, and such drivers would have to be greatly modified for use with other operating 

35 systems. 

An architecture known as the Common Access Method (CAM) is described in 'Systems Integration* vol 23, no 7, 
July 1990, pages 61-70. CAM defines a standard interface between operating systems and host bus adapters which 
is designed to overcome the problem of incompatibility between host bus adapters and device drivers. 

40 SUMMARY OF THE INVENTION 

A device driver system can generally be divided into two major parts, one part that interfaces with the operating 
system, and a second part that interfaces to the hardware and includes the specific information necessary to manage 
the I/O devices, we estimate that 10 to 20 percent of the development effort for creating new device drivers for use 

45 with a different operating system, is consumed by developing the one part, and the remaining 80 to 90 percent is 
consumed by developing the second part. One of the primary objectives of the invention is to provide a device driver 
core that is generic to a plurality of different operating systems without requiring modification. Such system also includes 
an operating system specific mapping layer for translating communications between a generic operating system inter- 
face in the core and a specific device driver interface in the operating system being used. When the core is used with 

50 a different operating system, only the mapping layer need be changed thus saving 80 to 90 percent of the development 
effort which would otherwise be consumed if an entire device driver system has to be written and developed. 
The invention is set forth in claim 1 . 

Briefly, in accordance with the invention, a device driver system comprises a core that manages the specific func- 
tions of a plurality of I/O devices. The core includes an operating system interface that is generic to different operating 

55 systems. An operating system has a device driver interface that is unique to the operating system. A conversion program 
is layered between the core and the operating system for converting communications between the device driver inter- 
face of the operating system and the generic operating system interface of the core. The device driver core includes 
a channel manager operable to receive I/O requests from the operating system, queue the requests, and translate the 
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requests into specific commands for the I/O devices. A transport layer is further provided as part of the device driver 
core to interface between the channel manager and the I/O devices. 

The objects and advantages of the invention will be apparent from the following description taken in connection 
with the accompanying drawings wherein: 

5 

Fig 1 is a block diagram of a data processing system embodying the invention; 
Fig 2 is a more detailed block diagram of a portion of the system shown in Fig 1 ; and 
10 Fig 3 is a more detailed block diagram of the operating system independent device driver shown in Fig 1 . 

DETAILED DESCRIPTION 

Referring now to the drawings, and first to Fig. 1 , there is shown a data processing system 10 operable under an 

W operating system (OS) to execute application programs 16. System 10 comprises a processor 12 connected to a bus 
system 14 which interconnects other elements of system 10. The other elements include a RAM (random access 
memory) 18, a keyboard 20, a display 22, a floppy disc drive 24, a fixed disc drive 26, and a plurality of MC (Micro 
Channel) connectors 28. Two SCSI adapters 30 and 30' are plugged into different ones of connectors 28. Adapter 30 
is connected to a SCSI bus 31 that in turn is connected to an optical SCSI device 32 and a tape SCSI device 33. 

20 Adapter 30' is connected to another SCSI bus 31 ' which in turn is connected to a tape SCSI device 34 and to a SCSI 
direct access storage device (DASD) 35. Adapter 30 includes a physical card state machine (PCSM) 36. Adapter 30' 
also includes a PCSM (not shown). Quite obviously, the type and number of adapter cards and I/O devices may vary 
from system to system dependent upon the user's needs and the illustrated system is to be considered exemplary only 
for purposes of understanding the invention. It is also to be noted that items 30 and 30' are referred to herein synon- 

25 omously and interchangably with the terms "adapter", "adapter card", and "card". 

Application programs 16 are stored in RAM 18 for execution by processor 12. The operating system includes a 
kernel 11 stored in RAM 18 for execution by processor 12. Also stored in RAM 18 is a three part, device driver system 
comprising OS specific device drivers (OSSDD) 38, an OS specific mapping layer (OSSML) 40, and a device driver 
core (DDC) 42. Except for the device driver system, (i.e. , items 38, 40, and 42) the other portions of system 1 0 described 

30 above are commercially available so that only so much of the details thereof as may be necessary for an understanding 
of the invention are described herein. OSSDD 38 comprises a set of device driver routines that are specific to the 
operating system and provide an interface to the OSSML 40 that conforms to the standard interface which the operating 
system presents to conventional device drivers. DDC 42 has an interface to the operating system which is generic to 
a plurality of operating systems. OSSML 40 is functionally layered between OSSDD 38 and DDC 42 to convert items 

35 passed between the standard operating system device driver interface and the generic device driver operating system 
interface. DDC 42 is implemented so as to be portable between different operating systems. Thus, should a different 
operating system be installed in system 10, DDC 42 can still be used but OSSDD 38 and OSSML 40 would have to 
be replaced to conform to the new operating system. 

Referring to Fig. 2, application programs 16 access I/O devices 32-35 by issuing I/O requests as system calls 43 

40 to the operating system. Such calls are received by OS kernel 11 which interprets the calls and then routes to an 
OSSDD dependent on the device class to which the request is directed. The illustrated system has two SCSI device 
classes, a DASD class and a tape class. The system thus has two OSSDD 38 and 38' for handling requests for the 
different classes. The OSSDD issue commands and send data over the standard operating system device driver in- 
terface 46 to OSSML which interprets and converts the commands so as to pass over device driver operating system 

45 interface 48 to DDC 42. OSSML also has two sections 40 and 40' corresponding to the two classes. Interface 46 
includes the following SCSI routines: dev-init, dev-start, dev-stop, dev-rw, dev-reserve, dev-close, dev-format, scsi- 
find-class, scsi-get-rtns, scsi -register-class, scsi-register-dev-rtns, begin-scsi-io, do-scsi-cmd, scsi-init, scsi-stopdev, 
get-inquiry, hddoread, hddowrite, and set-classO. Interface 46 also includes interfaces back to the OS kernel, including 
get-devno, report-err, io-done, and map-io. 

50 DDC 42 includes a plurality of class device drivers 50 and 52 which are respectively generic to the SCSI DASD 

class and the SCSI tape class. I/O requests received from interface 48 are directed to the appropriate class driver 
Four specific device drivers (SDD) drivers 54, 56, 58, and 60 provide driver functions specific or unique to each specific 
SCSI device. Drivers 54 and 56 provide specific driver functions for optical SCSI device 32 and DASD SCSI device 
35. Drivers 58 and 60 provide specific driver functions for tape devices 33 and 34. The two specific tape devices might 

55 be, for example, a 4 mm tape drive and an 8 mm tape drive requiring slightly different SDDs. DDC 42 further includes 
a channel manager 62 and a transport layer including a plurality of transport routines 64 and 66, there being one 
transport routine for each SCSI adapter in the system. 

OS kernel 11 also includes device driver help services 70 that are called by different routines in the device driver 
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system. Since OSSDD 38 is operating system specific, services 70 are called directly by calls 72. However, routines 
in DDC 42 issues calls 76 that are generic to such operating system services, and OSSML 40 translates such calls 
into calls 74 that are specific to the operating system. Such calls are generally for extraction routines to obtain infor- 
mation from the OS. 

5 Fig. 3 shows the relationship of further details of channel manager 62 to the transport layer and to state machines. 

Channel manager 62 comprises a request dispatcher 80, request queues 82, a command initiator 84, and a logical 
card state machines (CSM) 87. Channel manager 62 receives I/O requests in request dispatcher 80. When plural 
requests are received at about the same time, the requests are stacked internally in dispatcher and then serviced one 
at a time. Dispatcher 80 determines which SCSI device the request is for, performs any function that needs to be done 

10 before enqueing, builds a generic request block, and dispatches the request block to the corresponding device queue 
82. 

Device queue 82 comprises three parts, an enqueue function 92, a plurality of device request queues 94/n (where 
"n" identifies the associated I/O device), and a dequeue function 98. Each request queue is composed of individual 
request blocks 96. When a request block 96 is received from dispatcher 80, enqueue function 92 places the request 

is block on the queue 94 corresponding the I/O device for which the request has been made. Dequeue function 98, in 
response to receiving a message from command initiator 84 to transmit the next request block for a particular device, 
removes a request block 96 from a queue and transmits it to the requestor. The dequeuing function can be done in a 
variety of ways such as FIFO (first-in, first-out), priority levels, etc. 

Command initiator 84 translates request generic blocks 96 received thereby into SCSI specific request blocks 102 

20 that are then transmitted through one of transport layers 64 or 66 to a system state machine for the device to which 
the I/O request is directed. Command initiator builds one or more SCSI commands from each generic request or 
optimizes a plurality of generic requests into a single SCSI command. For example, multiple sequential disk reads can 
be optimized into a single SCSI read command. Since the transport layers are similar, only layer 64 is shown in Fig. 3 
for simplicity of illustration. Communications with layer 66 occurs through the paths shown at the right edge of initiator 

25 84. 

CSM 87 is logically the same as PCSM 36 and contains a card data structure 112 which among other items dis- 
cussed below, includes information on the state of the corresponding PCSM. CSM also includes a plurality of logical 
device state machines (LDSM) 88. There is one LDSM 88 for each I/O device in the system and the LDSMs are 
associated with the transport layer corresponding to the card to which the I/O devices are connected. Thus, LDSMs 

30 88/32 and 88/33 interact with transport layer 64, since devices 32 and 33 are connected to adapter 30 which layer 64 
corresponds to. Transport layer 64 is symbolically E-shaped and has three sublayers 64A-64C through which the 
various requests and messages pass. A request from initiator 84 is received by sublayer 64A which determines if the 
number of simultaneous requests being handled by the associated adapter exceeds the maximum number that the 
adapter can handle at any given time. If the adapter is too busy, the excess requests 102 are placed in a card request 

35 queue 100 until such time as they can be processed. If the adapter is not busy, the request is transmitted along path 
1 04 to sublayer 64B which determines if there is any pending request in an associated queue 1 00. If there is no pending 
request for a device, the current request is then transmitted to the appropriate LDSM 88. 

CSM 87 and LDSMs 88 are formed in memory 18 and are paired with and form models of corresponding physical 
device state machines (PDSMs). The PDSMs are the actual I/O devices which perform real I/O operations, and com- 

40 prise the internal latches, registers, and signals representing the physical state of the machine, and the device logic 
which responds to such stimuli for controlling operation of the device. Specifically, as shown in Fig. 3, LDSM 88/32 is 
a model of PDSM 32' and LDSM 88/33 is a model of PDSM 33'. Each logical and physical state machine recognizes 
the state the device is in and in response to a stimulus switches to another state dependent on the previous state and 
the nature of the stimulus. Thus, by way of example, suppose PDSM 33' has three states A', B\ and C\ The corre- 

45 sponding LDSM 88/33 also has three states A, B, and C corresponding to states A'-C\ Each LDSM is paired with 
PDSM and the paired state machines communicate with each other by messages transmitted through transport sub- 
layer 64C. The paired state machines are arranged for peer-to-peer control, as opposed to master/slave control, to 
provide novel functions and advantages set forth below. 

Using the example of the previous paragraph, a typical operation begins when command initiator 84 sends a 

so message (the request) along 104 to LDSM 88/33. This causes such state machine to switch from state A to state B. 
Part of this transition is to send a message or command to PDSM 33' via path 1 06 which causes the device to go from 
state A to state B\ Path 106 traverses transport sublayer 64C which builds the necessary command or control block 
for controlling operation of SCSI device 33. Such control block is sent along path 106. When device 33 completes the 
desired operation, PDSM 33' switches from state B* to state C Part of this transition is to send a response (results of 

55 command) back to LDSM 88/33 along path 108. Upon receipt of this message (results) LDSM 88/33 switches from 
state B to state C. Part of this transition is to send a message (results) via path 110 back to the command initiator, 
which can then get a new request from queue 94/33. 

Note that a LDSM does not have to always be the initiator of a request. A device and PDSM can also be an initiator. 



4 



EP 0 506 278 B1 

This implies that asynchronous processing can take place. 

Such state machine interaction provides several important functions and advantages. Synchronous devices (i.e., 
disks, tape) and non-synchronous devices (i.e., LAN and other communication devices) can be attached to the same 
bus/adapter combination. The state machine interaction allows for a symmetric relationship between synchronous 
processor driven devices (i.e., disks) and asynchronously driven devices (communication devices). Missing interrupt 
tracking is simplified for synchronous devices. In the corresponding state machine, there could be timed transitions. 
Such transitions allow solving the problem of when more buffers need to be allocated for communication devices. 
Symmetric state modeling allow an inboard device to manage the state of any outboard cache that may exist. Many 
of these functions are possible because all levels of the channel manager are extensible by device specific code. 
Standard code can be used and new code only needs to be written and developed for the areas of a device that are 
not covered by code in an existing subsystem. 

Contained in each CSM is a card data structure 11 2 the details of which vary from machine to machine in accord- 
ance with the details of the associated device. Each card data structure contains the following fields of information: 



15 


Field 


information 




1 


Card identifier information- ail information that describes the particular adapter card, i.e., I/O ports, memory 
mapped address, etc. 


20 


2 


Error information- place for storing error codes when an error occurs. 




3 


Card state- indicates current state the card is in, i.e., not initialized, not present, reset, error recovery 
procedure (ERP), initializing, busy, and broken. 


25 


4 


Flags- used to modify some of the behavior of the code for the card, mostly set when the card has been 
initialized. 




5 


Device state pointer- points to device state array. 


30 


6 


Transport function pointer- points to transport function for the card. 




7 


Work queue- queue of work for card to perform that is not on behalf of any device (device I/O requests are 
not on this queue). 



35 



All active state information about a card and the devices attached thereto are maintained off of the card state data 
structure 112. Such structures are maintained as an array of structures. The card number is used as an index into the 
array to access an individual structure for a particular card. By convention, on a PS/2 computer, the slot that a particular 
card is plugged into is used and the physical card number. 

40 Transport functions 1 1 4 are provided in the transport layers and are stored as a linked list, there being one transport 

function 114 for each type of adapter. The transport functions include data and routines including a pointer to next 
transport function in list, card identifier, presence test routine, initialization card routine, interrupt routine, output com- 
mand routine, reset routines, allocate command block routine, free end block routine, build command block routines, 
process card work queue routine, get status block routine, process command error routine, restart I/O routine, modify 

45 command block routine, and error reporting routines. 

When system 10 is initialized, each transport function is scanned until one is found to match the card being initial- 
ized. A match is found by using a combination of the card identifier field and by calling the presence test routine. When 
a match is found, a pointer to the individual transport function is placed in the appropriate card state structure. This 
permits fast access to the transport function for a particular card. Several card state structures may point to a specific 

so transport function if there are several of the same type of adapter cards in the system. 

Since several card state structures 112 can point to a particular transport function, the specifics for each card are 
kept in the card state structure as part of the card identifier. The transport function 114 in its card identifier field keeps 
the generic information for that type of card (i.e., a list of all possible I/O ports that control registers may appear at). 
The transport function isolates the specifics as to how an individual card performs some function. This is not to be 

S5 mistaken for a BIOS operation. The transport functions are mainly focused on specific delivery of commands to the 
card and responses back from the card. The transport functions are stateless in that all state information as to what 
activity is being performed is kept at higher levels. The transport function is called to perform some very specific func- 
tions on the card. 
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When I/O devices are added to the system and DDC 42 needs to be modified to control such devices, such mod- 
ifications can be included in code extensions which can be placed in one or more of the different portions of DDC 42 
as appropriate. Thus, code extensions (indicated by the E suffix) can be placed as extensions 80E to request dispatcher, 
extensions 92E and 98E to enqueue and dequeue functions 92 and 96, extensions 84E to the command initiator, and 
extensions 64E to transport layer 64. Extensions can also be made to the logical state machines. For example, suppose 
device 32 has three state X', V and Z* so that PDSM includes such states and when it was added to the system, an 
LDSM existed having only two states X and Y. LDSM 88/32 was formed by adding an extension corresponding to state Z. 



10 Claims 

1 . A data processing system comprising: 

a memory system (18) for storing application programs and an installed operating system, the operating system 
15 having a specific device driver interface for communicating with device drivers specifically designed for the 

operating system; 

a processor (12) for executing the application programs; 

20 a plurality of I/O devices (32,33,34,45); 

a generic device driver core (42) having a generic operating system interface generic to a plurality of different 
operating systems including the installed operating system, the device driver core being portable between 
different operating systems and having a plurality of device specific device drivers connected to the I/O devices 
25 for controlling operation thereof; and 

conversion means (40) functionally layered between the specific device driver interface of the installed oper- 
« ating system and the generic operating system interface of the device driver core, for converting I/O requests 
and responses between the specific device driver interface of the operating system and the generic operating 
30 system interface of the device driver core; 

characterised in that the device driver core comprises: 

a channel manager (62) operable to receive I/O requests from said operating system, queue the requests, 
35 and translate the requests into specific commands for the I/O devices; and 

a transport layer (64,66) interfacing between the channel manager and the I/O devices. 

2. A data processing system in accordance with claim 1 , wherein said device driver core comprises: 

40 

a plurality of I/O class device drivers covering different classes of I/O devices within said data processing 
system; 

and a plurality of device specific device drivers each covering a different I/O device within said data processing 
4$ system, said device specific device drivers being layered under said class device drivers according to device 

class. 

3. A data processing system in accordance with claim 1 wherein: 

50 said I/O devices comprise a plurality of physical device state machines (PDSMs); 

and said channel manager comprises a plurality of logical device state machines (LDSMs) each corresponding 
to a different one of said PDSMs and being paired therewith for communicating between each state machine 
in each pair. 

55 

4. A data processing system in accordance with claim 3 wherein: 

each pair of an LDSM and a PDSM are arranged for peer-to-peer control whereby such LDSM can cause such 
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PDSM to transit states by sending a command thereto, and such PDSM can cause such LDSM to transit states 
by sending a command thereto. 

5. A data processing system in accordance with claim 4 wherein: 

5 

said data processing system includes an adapter card for connection to a plurality of said I/O devices, said 
adapter card comprising a physical card state machine; 

and said channel manager comprises a logical card state machine modeled after said physical card state 
10 machine. 

6. A data processing system in accordance with claim 5 wherein: 

said transport layer comprises a plurality of sublayers and said logical state machines are sandwiched between 
15 said sublayers, whereby all I/O requests pass through said sublayers before reaching said logical state ma- 

chines. 

7. A data processing system in accordance with claim 6 wherein one of said sublayers is operative to determine, 
when an incoming I/O request is being sent to an I/O device attached to said adapter card, whether said adapter 

20 card is busy because it is currently handling a predetermined number of I/O requests, such one sublayer being 

further operative to place said incoming I/O request on a card request queue until when the number of I/O requests 
being handled by said card falls below said predetermined number. 



25 



8. A data processing system in accordance with claim 1 wherein said channel manager comprises: 

a plurality of request queues for temporarily storing I/O requests, there being one request queue for each I/O 
device; 

a request dispatcher for receiving I/O requests and dispatching such requests to one of said request queues 
30 according to which device each request is for. 

9. A data processing system in accordance with claim 8 wherein said channel manager further comprises: 

a plurality of logical state machines for controlling operation of said I/O devices; 

35 

a command initiator operable to receive I/O requests from said request queues and translate each request to 
a specific I/O command which is then sent to one of said state machines to operate one of said I/O devices 
in accordance with such specific I/O command. 

40 10. A data processing system in accordance with claim 9 wherein: 

said data processing system includes a SCSI bus, and said I/O devices are SCSI devices connected to said 
SCSI bus. 

45 11. A data processing system in accordance with claim 10 wherein: 

said data processing system comprises an adapter card connected to said SCSI bus and containing a physical 
card state machine (PCSM); 

so said channel manager comprises a logical card state machine (LCSM) corresponding to said PCSM, said 

LCSM containing a card state data structure settable to indicate a present state of said PCSM. 

12. A data processing system in accordance with claim 11 wherein: 

5 $ said transport layer comprises a transport function including routines for interfacing with said I/O devices; 

and said card data structure contains a pointer to said transport function. 
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10 



13. A data processing system in accordance with claim 1 wherein: 

said channel manager comprises extension routines for extending operation of said channel manager beyond 
preexisting limits. 

PatentansprOche 

1. Ein Datenverarbeitungssystem, folgendes umfassend: 

Ein Speichersystem (18) zum Speichern von Anwendungsprogrammen und ein installiertes Betriebssystem 
mit einer spezifischen Gratetreiber-Schnittstelle zur Kommunikation mit Geratetreibern, die speziell fur das 
Betriebssystem entwickelt wurden; 

1$ Einen Prozessor (12) zur Ausfuhrung der Anwendungsprogramme; 

Eine Vielzahl an E/A-Geraten (32, 33, 34, 45); 

Einen generischen Geratetreiberkern (42) mit einer generischen Betreibssystem-Schnittstelle, die generisch 
20 ist gegenOber einer Vielzahl verschiedener Betreibssysteme, einschlieBlich dem installierten Betriebssystem, 

wobei der Geratetreiberkern zwischen verschiedenen Betriebssystemen auswechselbar ist und uber eine Viel- 
zahl an geratespezifischen Geratetreibern verfugt, die mit den E/A-Geraten zur Steuerung des Betriebs ver- 
bunden sind; und 

25 Ein Umsetzungsmittel (40), das funktionell in Schichten zwischen der spezifischen Geratetreiber-Schnittstelle 

des installierten Betriebssystems und der generischen Betriebssystem-Schnittstelle des Geratetreiberkerns 
angeordnet ist, zur Umsetzung von E/A-Anforderungen und Antworten zwischen der spezifischen Geratetrei- 
ber-Schnittstelle des Betriebssystems und der generischen Betriebssystem-Schnittstelle des Geratetreiber- 
kerns; 

30 

dadurch gekennzeichnet, daf3 der Geratetreiberkern folgendes umfaBt: 

Einen Kanal-Manager (62) zum Empfang von E/A-Anforderungen vom genannten Betriebssystem, zum Ein- 
reihen der Anforderungen in der Warteschlange und zum Ubersetzen der Anforderungen in spezifische Be- 
35 fehle f Or die E/A-Gerate; und 

Eine Transportebene (64, 66) als Schnittstelle zwischen dem Kanal-Manager und den E/A-Geraten. 

2. Ein Datenvararbeitungssystem nach Anspruch 1 , bei dem der genannte Geratetreiberkern folgendes umfafit: 

Eine Vielzahl an E/A-Klasse-Geratetreibem, die verschiedene Klassen von Getratetreibern innerhalb des ge- 
nannten Datenverarbeitungssystem umfassen; 

Eine Vielzahl an geratespezifischen Geratetreibern, die jeder ein anderes E/A-Gerat innerhalb des genannten 
45 Datenverabeitungssystems abdecken, wobei die genannten geratespezifischen Geratetreiber unter den ge- 

nannten Klassen-Geratetreibern entsprechend der Gerateklasse gestaffelt sind. 

3. Ein Datenverarbeitungssystem nach Anspruch 1 , bei dem: 

50 Die genannten E/A-Gerate eine Vielzahl an physischen Geratestatusmaschinen (PGSMs) umfassen; 

und der genannte Kanal-Manager eine Vielzahl an logischen Geratestatusmaschinen (LGSMs) umfaBt, die 
jeweils einem anderen der PGSMs zugehorig sind und diesen paarweise angeordnet sind, urn zwischen jeder 
Statusmaschine in jedem Paar kommunizieren zu konnen. 

55 

4. Ein Datenverarbeitungssystem nach Anspruch 3, bei dem: 

Jedes Paar eine LGSM und eine PGSM fur eine Peer-to-Peer-Steuerung angeordnet sind, wobei diese LGSM 
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die PGSM zu einem Statuswechsel veranlaBt, indem es einen Befehl an diese sendet, und diese PGSM die 
LGSM zu einem Statuswechel veranlaBt, indem es einen Befehl an diese sendet. 

5. Ein Datenverarbeitungssystem nach Anspruch 4, bei dem: 

Das genannte Datenverarbeitungssystem eine Adapterkarte zur Verbindung mit einer Vielzahl der genannten 
E/A-Gerate umfaBt, wobei die genannte Adapterkarte eine physische Kartenstatusmaschine umfaBt; 

und der genannte Kanal-Manager eine logische Kartenstatusmaschine umfaBt, die nach der genannten phy- 
sischen Kartenstatusmaschine modelliert ist. 

6. Ein Datenverabeitungssystem nach Anspruch 5, bei dem: 

Die genannte Transportebene eine Vielzahl an Unterebenen umfaBt, und die genannten logischen Statusma- 
schinen zwischen den einzelnen genannten Unterbenen in Schichten angeortdnet sind, wobei alle E/A-Anfor- 
derungen die genannten Unterebenen durchlaufen, bevor sie die genannte logische Statusmaschine errei- 
chen. 

7. Ein Datenverarbeitungssystem nach Anspruch 6, bei dem eine der genannten Unterebenen dazu dient, zu be- 
stimmen, wann eine eingehende E/A-Anforderung an ein mit der genannten Adapterkarte verbundenes E/A-Gerat 
gesnedet wird, ob die genannte Adpaterkarte beschaftigt ist, da sie derzeit eine vomer bestimmte Anzahl an E/A- 
Anforderungen bearbeitet; diese Unterebene ist weiterhin daf Or zustandig ist, eingehende E/A-Anforderungen in 
einer Kartenanforderungs-Warteschlange zu plazieren, bis die Anzahl an von der genannten Karte verarbeiteten 
E/A-Anforderungen unterhalb der genannten vorher bestimmten Anzahl liegt. 

8. Ein Datenverarbeitungssystem nach Anspruch 1 , bei dem der genannte Kanal-Manager folgendes umfaBt: 

Eine Vielzahl an Anforderungswarteschlangen zur temporaren Speicherung von E/A-Anforderungen mit einer 
Anforderungswarteschlange fur jedes E/A-Gerat; 

Einer Anf order ungs-Zuteilerroutine zum Empfang von E/A-Anforderungen und zur Verteilung dieser Anforde- 
rungen an eine der Anforderungswarteschlangen, je nachdem, fur welches Gerat die jeweilige Anforderung 
bestimmt ist. 

9. Ein Datenverarbeitungssystem nach Anspruch 8, bei dem der genannte Kanal-Manager weiterhin folgendes um- 
faBt: 

Eine Vielzahl an logischen Statusmaschinen zur Steuerung des Betriebs der genannten E/A-Gerate; 

Einen Befehlsinitiatorzum Empfang von E/A-Anforderungen von den genannten Anforderungswarteschlangen 
und zur Ubersetzung jeder einzelnen Anforderung in einen spezifischen E/A-Befehl, der dann zu einer der 
genannten Statusmaschinen gesendet wird, urn eine der genannten Statusmaschinen entsprechend dem spe- 
zifischen E/A-Befehl zu bearbeiten. 

10. Ein Datenverarbeitungssystem nach Anspruch 9, bei dem: 

Das genannte Datenverarbeitungssystem einen SCSI -Bus umfaBt und es sich bei den genanten E/A-Geraten 
urn SCSI-Gerate handelt, die mit dem genannten SCSI-Bsu verbunden sind. 

11. Ein Datenverarbeitungssystem nach Anspruch 10, bei dem: 

Das genannte Datenverarbeitungssystem eine Adapterkarte umfaBt, die mit dem genannten SCSI-Bus ver- 
bunden ist und eine physische Kartenstatusmaschine (PKSM) umfaBt; 

Der genannte Kanal-Manager eine logische Kartenstatusmaschine (LKSM) umfaBt, die der genannten PKSM 
entspricht, wobei die genannte LKSM eine Kartenstatusdatenstruktur umfaBt, die zur Kennzeichnung des 
aktuellen Status der genannten PKSM eingesetzt werden kann. 
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12. Ein Datenverarbeitungssystem nach Anspruch 11, bei dem: 

die genannte Transportebene eine Transportebene umfafct, einschlie&lich Routinen fur die Schnittstellen mit 
den genannten E/A-Geraten; 

und die genannte Kartenstatusdatenstruktur eine'n Zeiger zur genannten Transportfunktion enthaft. 

13. Ein Datenverarbeitungssystem nach Anspruch 1, bei dem: 

Der genannte Kanal-Manager Erweiterungsroutinen zur Erweiterung des Betriebs des genannten Kanatm- 
amangers uber die bereits bestehenden Grenzen hinaus umfaBt. 



Revendications 

1 . Un systeme de traitement de donnees comprenant : 

un systeme memoire (18) concu pour stocker des programmes d'application et un systeme Sexploitation 
installe, le systeme d'exploitation ayant une interface de pilote de dispositif specifique pour communiquer avec 
des pilotes de dispositif, specif iquement concus pour le systeme d'exploitation; 

un processeur (12) congu pour executer les programmes d'application; 

une pluralite de dispositifs E/S (32, 33, 34, 35); 

un noyau de pilote de dispositif generique (42) ayant une interface de systeme d'exploitation generique, qui 
est generique a une pluralite de differents systemes d'exploitation, comprenant le systeme d'exploitation ins- 
talle, le noyau de pilote de dispositif 6tant portable entre des systemes d'exploitation differents et ayant une 
pluralite de pilotes de dispositifs specifiques au dispositif, connectes aux dispositifs E/S dans le but de com- 
mander leur fonctionnement; et 

des moyens de conversion (40) constitues fonctionnellement en couches, entre interface de pilote de dispositif 
specifique du systeme d'exploitation installs et I'interface de systeme d'exploitation generique du noyau de 
pilote de dispositif, dans le but de convertir les requetes E/S et les reponses entre I'interface de pilote de 
"dispositif specifique du systeme d'exploitation et I'interface de systeme d'exploitation generique du noyau de 
pilote de dispositif; 

caracterise en ce que le noyau de pilote de dispositif comprend : 

un gestionnaire de canal (62) pouvant fonctionner pour recevoir des requetes E/S depuis ledit systeme d'ex- 
ploitation, mettre en file d'attente les requetes, et traduire les requetes en des instructions specifiques pour 
les dispositifs E/S; et 

une couche de transport (64, 66) etablissant I'interface entre le gestionnaire de canal et les dispositifs E/S. 

2. Un systeme de traitement de donnees selon la revendication 1 , dans lequel ledit noyau de pilote de dispositif 
comprend : 

une pluralite de pilotes de dispositif de classe E/S, couvrant difterentes classes de dispositif E/S dans le 
systeme de traitement de donnees; 

et une pluralite de pilotes de dispositifs specifiques au dispositif, couvrant chacun un dispositif E/S different 
dans ledit systeme de traitement de donnees, lesdits pilotes de dispositifs specifiques au dispositif etant or- 
ganises en couche sous lesdits pilotes de dispositif de classe, en fonction de la classe du dispositif. 

3. Un systeme de traitement de donnees selon la revendication 1 , dans lequel : 

lesdits dispositifs E/S comprennent une pluralite de machines a etats constituant un dispositif physique 
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(PDSM); 

et ledit gestionnaire de canal comprenant une plurality de machines a etats formant un dispositif logique 
(LDSM) , correspondant chacune a Tune different parmi lesdites PDSM et etant groupees par paires avec 
elles pour communiquer entre chaque machine a etets dans chaque paire. 

4. Un systeme de traitement de donnees selon la revendication 3, dans lequel : 

chaque paire constitue d'une LDSM et d'une PDSM est agencee pour assurer une commande d'egal a 6gal 
de maniere que cette LDSM puisse provoquer le transfert par cette PDSM des etats en lui envoyant une 
instruction et cette PDSM peut provoquer le transfert par cette LDSM des elats lui envoyant une instruction. 

5. Un systeme de traitement de donnees selon la revendication 4, dans lequel : 

ledit systeme de traitement de donnees comprend une carte adaptatrice pour etablir la connexion a une plu- 
ralite desdits dispositifs E/S, ladite carte adaptatrice comprenant une machine a 6tats a carte physique; 

et ledit gestionnaire de canal comprend une machine a etats a carte logique, modelee d'apres ladite machine 
a etats a carte physique. 

6. Un systeme de traitement de donnees selon la revendication 5, dans lequel : 

ladite couche de transport comprend une plurality de sous-couches, et lesdites machines a 6tats logiques 
sont prises en sandwich entre lesdites sous-couches, de maniere que toutes les requetes E/S passe nt par 
lesdites sous-couches avant d'atteindre lesdites machines a etats logique. 

7. Un systeme de traitement de donnees selon la revendication 6, dans lequel I'une desdites sous-couches est ope- 
rationnelle pour determiner, lorsqu'une requete E/S entrante est envoyee a un dispositif E/S attache a ladite carte 
adaptatrice, si ladite carte adaptatrice est occupee parce qu'elle est actuellement en train de traiter un nombre 
predetermine de requetes E/S, une telle sous-couche etant en outre operationnelle pour placer ladite requete E/ 
S (1 30) sur une file d'attente de requetes de carte, jusqu'a ce que le nombre des requetes E/S en cours de traitement 
par ladite carte devienne inferieure audit nombre predetermine. 

8. Un systeme de traitement de donnees selon la revendication 1 , dans lequel ledit gestionnaire de canal comprend : 

une pluralite de files d'attente de requetes pour stocker temporairement les requetes E/S, une file d'attente 
de requetes etant prevue pour chaque dispositif E/S; 

un repartiteur de requetes, destine a recevoir les requetes E/S eta distribuer lesdites requetes a I'une desdites 
files d'attente de requetes, en fonction du dispositif pour lequel chaque requete est destinee. 

9. Un systeme de traitement selon la revendication 8, dans lequel ledit gestionnaire de canal comprend en outre : 

une pluralite de machines a etats logique destinees a commander le fonctionnement desdits dispositifs E/S; 

un lanceur d' instructions, pouvant fonctionner pour recevoir des requetes E/S venant desdites files d'attente 
de requetes et traduire chaque requete en une instruction E/S specif ique qui est ensuite envoyee a I'une 
desdites machines a 6tats, afin de faire fonctionner Tun desdits dispositifs E/S selon cette instruction E/S 
spec if ique. 

10. Un systeme de traitement de donnees selon la revendication 9, dans lequel : 

ledit systeme de traitement de donnees comprend un bus SCSI et lesdits dispositifs E/S sont des dispositifs 
SCSI connected audit bus SCSI. 

11. Un systeme de traitement de donnees selon la revendication 10, dans lequel : 

ledit systeme de traitement de donnees comprend une carte adaptatrice connectee audit bus SCSI et conte- 
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nant une machine a etats a carte physique (PCSM); 

ledit gestionnaire de canal comprend une machine a elats a carte logique (LCSM) correspondant a ladite 
PCSM, ladite LCSM contenant une structure de donnees d'etat de carte pouvant etre fixee pour indiquer Tetat 
actuel de ladite PCSM. 

Un systeme de traitement de donnees selon la revendication 11, dans lequel : 

ladite couche de transport comprend une fonction de transport incluant des sous-programmes destines a 
assurer Tinterface avec lesdits dispositifs E/S; 

et ladite structure de donnees de carte contient un pointeur allant a ladite fonction de transport. 

Un systeme de traitement de donnees selon la revendication 1 , dans lequel : 

ledit gestionnaire de canal comprend des sous-programmes d'extension, destines a etendre le fonctionnement 
dudit gestionnaire de canal au-dela des limites preexistantes. 
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